Smartcards are becoming increasingly more popular for security and personal identification applications. For example, smartcards are currently used for storing sensitive data such as medical records, banking information, and similar data requirements. In perhaps their most common form, smartcards have a card body that resembles a credit card in size, shape, and thickness, and may be made out of similar materials, for example, plastic. Rather than having a magnetic stripe to store sensitive information (e.g., account numbers, user identification, etc.) as standard credit cards do, smartcards generally include an integrated circuit (IC). The IC not only includes a non-volatile memory for storing sensitive data, but it may also include a microprocessor for processing this data and communicating with a host device via a card reader, for example. Not only can smartcards store more information than magnetic stripe cards, but also they have much greater functionality.
Various protocols have emerged to standardize the operation and communications of devices such as smartcards. One of the earliest of these was developed by the International Organization for Standardization (ISO) and is known as the ISO 7816-X protocol. In particular, this protocol is set forth in ISO documents ISO 7816-1 (Physical Characteristics), ISO 7816-2 (Dimensions and Locations of Contacts), ISO 7816-3 (Electronic Signals and Transmission Protocols), ISO 7816-10 (Electronic Signals and Answer to Reset for Synchronous Cards), and ISO 7816-12 (USB Interface) for example, all of which are hereby incorporated herein in their entirety by reference.
Furthermore, in response to the increasing popularity of the universal serial bus (USB) architecture, increasing numbers of smartcards continue to be developed which operate in accordance with the USB protocol. This protocol is set forth in the Universal Serial Bus Specification, Revision 2.0, Apr. 27, 2000, published by USB Implementers Forum, Inc., which is hereby incorporated herein in its entirety by reference. The USB architecture is particularly advantageous because it provides a standard “plug and play” interface for devices external to a computer, for example. External peripheral devices can be relatively quickly and easily installed and removed from a host device, e.g., a computer, without having to reboot or power down the computer.
Most product development cycles for complex computing systems or devices require a functional equivalent of the product before the final product is available. This functional equivalent is typically referred to as an emulator, or hardware emulator (HWE). The HWE allows the application developers for the product to develop and debug software applications for the device while the product engineers finalize and test the physical circuitry and/or components of the product.
With respect to smartcards, a HWE emulator is commonly used to develop, test, and debug new applications which will ultimately become embedded in the final smartcard integrated circuit. The HWE should provide functionality that matches as closely as possible the real-world functionality of the end product (e.g., a smartcard integrated circuit). This emulation should also be applicable to complicated dual-mode smartcards, such as dual ISO/USB smartcards. One such dual mode smartcard is described in U.S. Pat. No. 6,439,464 to Fruhauf et al., assigned to the assignee of the present invention, and which is hereby incorporated herein in its entirety by reference.
Electronic Design Automation (EDA) software tools are often used to simulate a smartcard (or other) chip design prior to prototyping or production. Designers often use a Hardware Description Language (HDL), such as Verilog® or VHDL, to define functional components and decompose them into smaller components. Software routines are placed and routed into logic cells at specific coordinate locations in a circuit layout.
Functional blocks, also called virtual component (VC) blocks, virtual components, or IP blocks, are often used by designers as pre-designed circuit functions. In many cases, these functional blocks are pre-hardened or semi-hardened circuit designs in software form that are re-used or recycled into larger circuit designs. The use of virtual component blocks reduces overall circuit design time and increases the speed a final design can reach market. These functional blocks as virtual components can also be pre-tested and verified from logical and functional standpoints.
Emulators often use functional blocks and a baseline architecture with the Virtual Socket Interface (VSI) for any “system-on-a-chip” (SoC) solution. Some functional blocks are specifically designed for use with a particular IC, and other functional blocks are designed for use with other IC's and obtained from internal company sources and/or external sources.
The Virtual Socket Interface (VSI) Alliance™ Architecture Document Version 1.0, the disclosure which is hereby incorporated by reference in its entirety, specifies the hardware and software interfaces, formats and design practices for creating functional blocks to enable efficient and accurate integration, verification and testing of multiple blocks on a single piece of silicon. The VSI standard is operative with an HDL description to allow IC design to be done using a component based solution. Virtual components as functional blocks are used in the design environment, and more particularly, a virtual socket design environment. Typically, virtual components can be soft, firm or hard. Usually a virtual component is a functional block designed to a set of specifications having an output that is a standard format with a pre-defined set of characteristics to simplify integration and verification.
In a design cycle for a USB smartcard, the design should be validated against as many test cases. Any modifications necessitate that it be re-validated against the test cases. Generation of test cases is a time-consuming and error-prone process. It has usually not been amenable to automation.
The development of a product, such as a USB smartcard device, requires work to be performed in multiple domains. Usually, engineers working in one domain produce test cases that are similar, but not necessarily identical, to those test cases developed in another domain. Test development within different domains is rarely shared. This duplication of efforts to develop these unshared tests is not necessary and is costly because it uses available resources and manpower. There is often little correlation between testing among different involved domains, yet much of the functionality requiring an exercise of skill is common across domains.
As of now, there has been no known mechanism for defining USB traffic patterns and scenarios, which may then be translated into a suitable format for a variety of development tools across the domains.
In the example of USB bus traffic, test cases and scenarios must be developed that exercise various portions of the hardware, software and firmware of a USB smartcard device. Any “expected” results should be crafted for each test case and scenario to compare against any collected “actual” data. Examination of the tools and techniques used in each domain reveal a strong correlation with respect to the nature of required test cases and scenarios.
Additionally, it is typical for each domain to use developers that are not common with the other domains. This could result from a particular expertise or skill of individual developers or when developers are separated by distance or time zones. As a result, it is common that the quality and quantity of tests, scenarios and data vary widely during the development process. There are also issues with cross-domain correlation. If all developers could agree upon a top-level implementation of a set of common and agreed upon tests and scenarios, and have appropriate programs and data automatically generated, many of these previously described problems would be corrected. This would be particularly true in an organization where project-associated domains occur in widely disbursed geographic locations.